home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-03-06 | 4.3 KB | 122 lines | [TEXT/GEOL] |
- Item forwarded by PAPERFREE to PERSOFT
-
- Item 1079984 25-Aug-90 20:17PDT
-
- From: D2022 Strata, Gary Bringhurst,PRT
-
- To: MACAPP.TECH$ MacApp Technical
-
- Sub: Unresolved MacApp 2.0 bugs
-
- My life is one long series of frustrations. If you don't believe me, just ask
- my wife. This week I received system 6.0.6b11, installed it for testing, and
- found to my joy and surprise that ALL MacApp 2.0 final applications BOMB
- HORRIBLY under it. Then I spent a couple of days updating MacApp with the
- published bug fixes. Happily, this appears to eliminate all bombs under system
- 6.0.6b11. Unhappily we are now in the position of having to update our user
- base "one more time." It appears that the new system has simply smoked out
- some nasty bugs that were just lurking in the shadows.
-
- For the MacApp boys: There are several side-effects resulting from the bug
- fixes for MacApp 2.0 final. Once again (yet again?) we have been burned by
- "semantic changes" in MacApp when once we thought it stable. In particular I
- must ask, why has TView.IsViewEnabled been changed to be dependent upon
- TView.IsShown??? It appears to be a modification that was convenient for
- MacApp, but has really screwed the pooch on our side. Whether or not a view is
- shown has no relevance to whether it is enabled. If you must avoid dinking on
- a hidden enabled control, please just check to see that it is both visible and
- enabled. Now many of the preparations we make in our code before posing a
- modal dialog window, such as selecting an EditText field, do not work as
- expected because the window is not yet shown, therefore the controls are
- assumed disabled and the floating edit text is not properly initialized.
-
- So, for everyone out there -- your MacApp 2.0 based applications are much more
- unstable than you would ever have believed. Beware!
-
- Gary L. Bringhurst
- Strata Inc.
- D2022
-
- P.S. One of my early links about bugs in MacApp 2.0 has been quoted to provide
- the title for technical note #280: "Bugs in MacApp? Yes, but I love it!" Can
- I take it back now? I think my enthusiasm for a buggy MacApp has gone along
- with my stomach lining.
-
- "The paranoia and frustration expressed above is my own, and does not reflect
- the paranoia and frustration of Strata or its management."
-
-
- --------
- The following list consists of additional bugs in the MacApp 2.0 final code
- that are not addressed by the bug fix package just released: (please note that
- the windowKind field contains the window "class," such as dialogKind or
- userKind, NOT the window variant)
-
-
- *** TApplication.InModalMenuState
-
- -- Current fixed version:
- IF (WMgrToWindow(aWindowPtr) = NIL) & (aWindowPtr <> NIL) THEN
- CASE WindowPeek(aWindowPtr)^.windowKind OF
- dBoxProc, plainDBox, altDBoxProc:
- InModalMenuState := TRUE;
- END
- ELSE
-
- -- Really fixed version:
- IF (WMgrToWindow(aWindowPtr) = NIL) & (aWindowPtr <> NIL) THEN BEGIN
- IF TrapExists(_GetWVariant) THEN
- windowVariant := GetWVariant(aWindowPtr)
- ELSE
- windowVariant := BAND($0F,
- BSR(LONGINT(WindowPeek(aWindowPtr)^.windowDefProc), 24));
- CASE windowVariant OF
- dBoxProc, plainDBox, altDBoxProc:
- InModalMenuState := TRUE;
- END;
- END ELSE
-
-
- *** TApplication.InModalState
-
- -- Current fixed version:
- IF (WMgrToWindow(aWindowPtr) = NIL) & (aWindowPtr <> NIL) THEN
- CASE WindowPeek(aWindowPtr)^.windowKind OF
- dBoxProc, plainDBox, altDBoxProc:
- InModalState := TRUE;
- END
- ELSE
-
- -- Really fixed version:
- IF (WMgrToWindow(aWindowPtr) = NIL) & (aWindowPtr <> NIL) THEN BEGIN
- IF TrapExists(_GetWVariant) THEN
- windowVariant := GetWVariant(aWindowPtr)
- ELSE
- windowVariant := BAND($0F,
- BSR(LONGINT(WindowPeek(aWindowPtr)^.windowDefProc), 24));
- CASE windowVariant OF
- dBoxProc, plainDBox, altDBoxProc:
- InModalState := TRUE;
- END;
- END ELSE
-
-
-
- *** DoInitUMemory
-
- -- Current fixed version:
- { Figure the highest segment number }
- IF qNeedsROM128k | gConfiguration.hasROM128k THEN
- lastRsrc := MACount1Resources(kCode) - 1
- ELSE
- lastRsrc := MACountResources(kCode) - 1;
-
- -- Really fixed version:
- { Figure the highest segment number. (Why were we avoiding the last code
- segment???)}
- IF qNeedsROM128k | gConfiguration.hasROM128k THEN
- lastRsrc := MACount1Resources(kCode)
- ELSE
- lastRsrc := MACountResources(kCode);
-
-